1. Technical Field
Exemplary embodiments presented herein relate to distributed computing, and more particularly to providing a consistent view of data that resides on a network and that can change dynamically in an uncoordinated way.
2. Description of the Related Art
The following is a survey of concepts, systems and protocols used in the prior art to provide background for the present invention.
Domain Name System (DNS) is an instance of a distributed database enabling local control of segments of the overall database and global access to the aggregate data in a client-server scheme. The servers in a DNS system are called name servers; the clients are called resolvers.
Name servers are delegated responsibility for a zone, the part of the total data they are controlling authoritatively. To increase availability of DNS data and achieve scalability, DNS deploys primary and secondary master name servers. The primary master loads the data the primary master is responsible for from files, while the secondary master obtains and updates data from the primary master in an action called zone transfer.
Request for Comments document for Tokyo Institute of Technology in the category of Standards Track (RFC 1995) describes an incremental zone transfer protocol, which permits a secondary master to pull only those zone changes it needs to synchronize its copy of the zone with the source maintained by the primary master. Versions of zone data are identified by serial numbers. These numbers are exchanged as part of the SOA (start of authority) record.
If the serial number for the zone at the primary master is greater than at the requesting secondary master, the transfer includes only those changes to RRs (resource records) for each incremental version of the zone. The primary master must maintain a history of incremental zone changes to be able to compute the proper set of RR updates between the current version and the version of the requesting secondary master.
Control Version System (CVS) is a version control system that supports the recording of file change histories. CVS maintains a repository of all files under version control. CVS users may retrieve (check out) versions of files, store them in a working directory in the local file system, modify the copies, and commit (check in) the modified files to the repository. The repository is physically separate from the working directory. The repository may reside on the local machine or on a remote CVS server.
Rather than storing all different versions of a file, the repository stores all versions in a single file and only records the differences between versions. CVS assigns a version number is of each committed version of a file. A particular version of a file may be extracted from the repository using either its version number or the date when it was checked in. CVS supports team programming by insulating developers from each other. Developers may simultaneously edit local copies of the same file. CVS merges the work when the local copies are checked in.
OSGi's (Open Services Gateway Initiative) primary goal is to define and foster rapid adoption of open specifications for the delivery of managed broadband services to networks in homes, cars and other environments. The OSGi Service Platform is a JAVA™ framework for developing remotely deployed service applications. OSGi provides life cycle management for services installed on the platform—services can be installed, started, stopped, updated and removed without disturbing other services within the platform. Services can locate each other and advertise their services through the registry. A service can also request that the framework notify it when another service becomes available or another state change occurs. Version management is provided by the platform, and the platform itself can be controlled remotely.
OSGi SPR3 defines specifications and JAVA™ application programming interfaces (APIs) that define the core functions of the platform and an application lifecycle, and provide a service registry, package and version management, and remote management ability. These APIs are then implemented by OSGi Service Platform implementations such as SMF (Service Management Framework). SMF is IBM®'s OSGi implementation; SMF 3.5 implements OSGi Service Platform Release 3 (SPR3).
OSGi (and SMF) applications are called bundles. A bundle is a JAR file containing the resources to implement services, and a manifest file with bundle information. A bundle can also act as a library, and only export JAVA™ packages. Bundles are stored in a SMF bundle server and are deployed from the server to the SMF runtime. The SMF platform can install, update, and uninstall bundles dynamically. Code within bundles can execute searches to find services registered by other bundles. The bundle lifecycle contains six states: installed, resolved, starting, active, stopping, and uninstalled.
The SMF bundle server maintains a bundle catalog, and can be shared by multiple developers. The SMF bundle server interacts with a management agent for the SMF runtime, and provides bundle “snapshots” and dependency checking for loading bundles. Snapshots are a way to store the current state of the runtime for later use, such as during recovery or reset. A typical use for snapshots is for developers to load all of the bundles needed on a particular target runtime and then to save the snapshot so that they can test different configurations and still be able to return to the previous state.
The bundle developer uses the Safe Bundle Install Protocol to install bundles into the runtime. The runtime provide the SMF bundle server with its configuration data and a list of currently installed bundles. The bundle server then determines the correct version of a bundle, resolves the bundle before it is downloaded by determining whether all the required packages and services are available in the runtime, and provides a list of prerequisite bundles needed by the runtime.
Although SMF uses bundle snapshots, they are unrelated to bundle updates, but store the current state of the SMF Runtime. Thus, using the snapshot, a particular runtime environment can be restored. Particular bundles are updated by downloading the latest version from the bundle server upon user request.
Tightly-Integrated Client/Server Systems are systems in which a client program executes a private protocol with a server program which requires tight integration between these two communicating components. Typically, the client and server components are developed together and are intended to run together. For performance or other reasons, data that resides on the server is often replicated on the client as part of the client/server protocol. Similarly, for recovery or other reasons, data that resides on the client may be replicated on the server.
LOTUS NOTES® is an example of a client/server system in which the protocol between the client and server components implements data replication. In LOTUS NOTES®, databases that reside on either the client or the server can be replicated elsewhere on the network. For example, a person's e-mail database usually resides on a “Notes” server and is often replicated on the “Notes” client. This replication allows fast access to e-mail documents on the client platform, whether or not the client is connected to the network.
Distributed server systems and distributed, multiple-server systems often require closely coordinated server execution and explicitly synchronized server data. Distributed Database Management Systems (DDBMS), for example, replicate databases according to well-defined protocols for performance and availability reasons.
Standard web browsers, such as INTERNET EXPLORER® or MOZILLA™, allow web applications to store data in cookies that reside on the client machine that runs the browser. These cookies usually store a small amount of application data, such as user preferences or session identifiers, which the browser will send on future requests to the application server.